RRC Protocol States:
In LTE, a terminal can be in two different states, as shown in FIG. 1, RRC_CONNECTED and RRC_IDLE.
In RRC_CONNECTED, there is an RRC context. The cell to which the UE belongs is known and an identity of the UE, the Cell Radio-Network Temporary Identifier (C-RNTI), used for signaling purposes between the UE and the network, has been configured. RRC_CONNECTED is intended for data transfer to/from the UE.
In RRC_IDLE, there is no RRC context in the Radio Access Network (RAN) and the UE does not belong to a specific cell. No data transfer may take place in RRC_IDLE. A UE in RRC_IDLE monitors a Paging channel to detect incoming calls and changes to the system information. Discontinuous Reception (DRX) is used to conserve UE power. When moving to RRC_CONNECTED, the RRC context needs to be established in both the RAN and the UE.
FIG. 2 provides an overview of the RRC states in E-UTRA with the illustration of the mobility support between E-UTRAN, UTRAN and GERAN.
Mobility State of UE (3GPP TS 36.304 User Equipment (UE) Procedures in Idle Mode (Release 13), V13.0.0):
Besides Normal-mobility state, a High-mobility and a Medium-mobility state are applicable if the parameters (TCRmax, NCR_H, NCR_M and TCRmaxHyst) are sent in the system information broadcast of the serving cell. Note: These states should be considered substates as related to mobility in RRC_IDLE state. NCR_M specifies the maximum number of cell reselections to enter Medium-mobility state. NCR_H specifies the maximum number of cell reselections to enter High-mobility state. TCRmax specifies the duration for evaluating allowed amount of cell reselection(s). TCRmaxHyst specifies the additional time period before the UE can enter Normal-mobility state.
State detection criteria include medium-mobility state criteria or high-mobility state criteria. Medium-mobility state criteria: If number of cell reselections during time period TCRmax exceeds NCR_M and not exceeds NCR_H. High-mobility state criteria: If number of cell reselections during time period TCRmax exceeds NCR_H. The UE shall not count consecutive reselections between same two cells into mobility state detection criteria if same cell is reselected just after one other reselection.
State transitions: The UE shall: 1) if the criteria for High-mobility state is detected, enter High-mobility state; else if 2) the criteria for Medium-mobility state is detected, enter Medium-mobility state; else if 3) else if criteria for either Medium- or High-mobility state is not detected during time period TCRmaxHyst, enter Normal-mobility state
NAS Protocol:
Detail of NAS Protocol for LTE are described in 3GPP TS 23.401 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 13), V13.6.1 and 3GPP TS 24.302 Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3 (Release 13), V13.5.0. A summary is provided below.
The non-access stratum (NAS) forms the highest stratum of the control plane between UE and MME at the radio interface over the reference point Uu. Main functions of the protocols that are part of the NAS are: the support of mobility of the user equipment (UE); and the support of session management procedures to establish and maintain IP connectivity between the UE and a packet data network gateway (PDN GW).
As such, the NAS consists of two separate protocols that are carried on direct signaling transport between the UE and for e.g., the MME in the Core Network (CN). The content of the NAS layer protocols is not visible to the Radio Access Network (RAN) nodes (e.g., eNodeB), and the RAN nodes are not involved in these transactions by any other means, besides transporting the messages, and providing some additional transport layer indications along with the messages in some cases. NAS layer protocols include EPS Mobility Management (EMM) and EPS Session Management (ESM).
EPS Mobility Management (EMM): The EMM protocol is responsible for handling the UE mobility within the system. It includes functions for attaching to and detaching from the network, and performing location updating in between. This is called Tracking Area Updating (TAU), and it happens in idle mode. Note that the handovers in connected mode are handled by the lower layer protocols, but the EMM layer does include functions for re-activating the UE from idle mode. The UE initiated case is called Service Request, while Paging represents the network initiated case. Authentication and protecting the UE identity, i.e. allocating the temporary identity Globally Unique Temporary UE Identity GUTI to the UE are also part of the EMM layer, as well as the control of NAS layer security functions, encryption and integrity protection. Example of EMM procedures include attach procedure (for registration), detach procedure, service request procedure, tracking area update procedure, connection suspend, connection resume procedure and UE reachability procedure. NAS security is an additional function of the NAS providing services to the NAS protocols, e.g., integrity protection and ciphering of NAS signaling messages.
EPS Session Management (ESM): This protocol may be used to handle the bearer management between the UE and MME, and it is used in addition for E-UTRAN bearer management procedures. Note that the intention is not to use the ESM procedures if the bearer contexts are already available in the network and E-UTRAN procedures can be run immediately. This would be the case, for example, when the UE has already signaled with an operator affiliated Application Function in the network, and the relevant information has been made available through the PCRF.
The overall Evolved Packet System Control Plane Protocol stack is depicted in FIG. 3.
Linkage Between the Protocols for EPS Mobility Management and EPS Session Management:
During the EPS attach procedure, the network can activate a default EPS bearer context (i.e. if the UE requests PDN connectivity in the attach request). Additionally, the network can activate one or several dedicated EPS bearer contexts in parallel for PDN connections of IP PDN type. To this purpose the EPS session management messages for the default EPS bearer context activation are transmitted in an information element in the EPS mobility management messages. In this case, the UE and the network execute the attach procedure, the default EPS bearer context activation procedure, and the dedicated EPS bearer context activation procedure in parallel. The UE and network shall complete the combined default EPS bearer context activation procedure and the attach procedure before the dedicated EPS bearer context activation procedure is completed. The success of the attach procedure is dependent on the success of the default EPS bearer context activation procedure. If the attach procedure fails, then the ESM procedures also fail. Except for the attach procedure and the service request procedure, during EMM procedures the MME shall suspend the transmission of ESM messages. During the service request procedure the MME may suspend the transmission of ESM messages. Except for the attach procedure, during EMM procedures the UE shall suspend the transmission of ESM messages.
NAS Protocol States:
The EMM sublayer main states in the UE are illustrated in FIG. 4. The eMM sublayer states in the MME are illustrated in FIG. 5. ESM Sublayer State in the UE are shown in FIG. 6. ESM Sublayer State in the MME are shown in FIG. 7.
Cell Selection and Reselection:
The cell selection and reselection procedures performed by a UE in RRC_IDLE are described in section 5.2 of 3GPP TS 36.304. FIG. 8 is high level flow chart illustrating the cell selection and reselection processing performed by a UE in RRC_IDLE. The procedure is entered whenever a new PLMN is selected or if a suitable cell can't be found upon leaving RRC_CONNECTED. After a cell is selected, the UE camps on the cell and performs the tasks defined in section 5.2.6 or 5.2.9 of 3GPP TS 36.304, depending on whether the UE has camped on a suitable cell or an acceptable cell respectively. When camped on a cell, the UE shall regularly search for a better cell according to the cell reselection criteria, as defined in section 5.2.3.2 of 3GPP TS 36.304.
The Cell Reselection Evaluation process is performed according to internal UE triggers or when information on the BCCH used for the cell reselection evaluation procedure has been modified. Upon re-selecting a cell, a UE in RRC_IDLE is required to apply the System Information Acquisition procedure as defined in section 5.2.3 of 3GPP TS 36.331 to obtain the system information for the new serving cell.
IMT 2020:
IMT for 2020 and beyond is envisaged to expand and support diverse families of usage scenarios and applications that will continue beyond the current IMT. Furthermore, a broad variety of capabilities would be tightly coupled with these intended different usage scenarios and applications for IMT for 2020 and beyond. The families of usage scenarios for IMT for 2020 and beyond include eMBB, URLLC, mMTC, and NEO.
eMBB (Enhanced Mobile Broadband)                Macro and small cells        1 ms Latency (air interface)        Spectrum allocated at WRC-15 may lead up to 8 Gbps of additional throughput        Support for high mobility        
URLLC (Ultra-Reliable and Low Latency Communications)                Low to medium data rates (50 kbps-10 Mbps)        <1 ms air interface latency        9.999% reliability and availability        Low connection establishment latency        0-500 km/h mobility        
mMTC (Massive Machine Type Communications)                Low data rate (1˜100 kbps)        High density of devices (up to 200,000/km2)        Latency: seconds to hours        Low power: up to 15 years battery autonomy        Asynchronous access        
NEtwork Operation (NEO) addresses the subjects such as Network Slicing, Routing, Migration and Interworking, Energy Saving, etc.
The following deployment scenarios are being considered primarily for eMBB (see 3GPP TR 38.913 Study on Scenarios and Requirements for Next Generation Access Technologies; (Release 14), V0.2.0). Deployment scenarios for mMTC and URLLC are still under study; however, the eMBB deployment scenarios below are likely to also be applicable to mMTC and URLLC. The following 5 deployment scenarios are being considered for eMBB: Indoor Hotspot, Dense Urban, Rural, Urban Macro, and High Speed.
Indoor Hotspot: this deployment scenario focuses on small coverage per site/TRP (Transmission and Reception Point) and high user throughput or user density in buildings. The key characteristics of this deployment scenario are high capacity, high user density and consistent user experience indoor.
Dense Urban: the dense urban microcellular deployment scenario focuses on macro TRPs with or without micro TRPs and high user densities and traffic loads in city centers and dense urban areas. The key characteristics of this deployment scenario are high traffic loads, outdoor and outdoor-to-indoor coverage.
Rural: this deployment scenario focuses on larger and continuous coverage. The key characteristics of this scenario are continuous wide area coverage supporting high speed vehicles.
Urban Macro: the urban macro deployment scenario focuses on large cells and continuous coverage. The key characteristics of this scenario are continuous and ubiquitous coverage in urban areas.
High Speed: Beyond 2020, there will be a growing demand for mobile services in vehicles, trains and even aircrafts. While some services are the natural evolution of the existing ones (navigation, entertainment, etc.), some others represent completely new scenarios such as broadband communication services on commercial aircrafts (e.g., by a hub on board). The degree of mobility required will depend upon the specific use case, with speeds greater than 500 km/h.
Additionally, the following deployment scenario, urban coverage for massive connection, has been identified specifically for mMTC use case. Urban coverage for massive connection: The urban coverage for massive connection scenario focuses on large cells and continuous coverage to provide mMTC. The key characteristics of this scenario are continuous and ubiquitous coverage in urban areas, with very high connection density of mMTC devices. This deployment scenario is for the evaluation of the KPI of connection density.
Furthermore, the following deployment scenarios have been identified for UR/LL use case: Highway Scenario and Urban Grid for Connected Car. Highway Scenario: The highway deployment scenario focuses on scenario of vehicles placed in highways with high speeds. The main KPIs evaluated under this scenario would be reliability/availability under high speeds/mobility (and thus frequent handover operations).
Urban Grid for Connected Car: The urban macro deployment scenario focuses on scenario of highly densely deployed vehicles placed in urban area. It could cover a scenario where freeways lead through an urban grid. The main KPI evaluated under this scenario are reliability/availability/latency in high network load and high UE density scenarios.
Example of mMTC Applications:
First Example—Light Weight Device: Light Weight Device—very simple device with e.g., with no IMS client (5.1.2.1 of 3GPP TR 22.861), the device could be, for example, a smart electric meter. It records electricity usage, provides up to the minute usage reports that allow the customer to take advantage of time of day rating, and provides a larger, complete report to the electric company once a month. The electric company deploys a large number of these smart meters within an apartment building, one for each apartment.
Second Example—Video Surveillance with variable data size: The application here is a video Surveillance with variable data size (5.1.2.2 of 3GPP TR 22.861). A video recorder is installed and activated at a street corner. The video recorder includes a camera, some on-board processing capability, as well as the ability to send information to the traffic police. The camera records continuous video, storing the content for some period of time. The device periodically sends a status update to the traffic police indicating that traffic is moving smoothly
When an accident occurs at the intersection, the device begins sending high quality video to the traffic police of the accident and ensuing traffic congestion.
Note: The network will need the flexibility to provide efficient service to the device at all times, whether a small or large amount of data is sent in a given transmission. An efficient system could minimize any negative impact to battery life for the device and minimize use of signaling resources. The same device will need to establish a connection when it needs to transmit a large amount of data (e.g., video).
Third Example—Warehouse Application (5.2.3.1 of 3GPP TR 22.861 Feasibility Study on New Services and Markets Technology Enablers for Massive Internet of Things; Stage 1 (Release 14), V1.0.0): In this application, the coverage area is limited. Most likely the IoT devices in a given deployment are owned by same entity devices will range from very simple, limited function devices to very complex, sophisticated computing platforms. On the lower end of the device function range, not all such devices may use IMS and may not need to be equipped with an IMS client, and yet it would still be desirable to activate such a device remotely due to sensor deployment configurations.
Example of UR/LL Applications:
First Example—Industrial Process Control (5.1.2.2 of 3GPP TR 22.862): Process automation requires communications for supervisory and open-loop control applications, process monitoring and tracking operations on field level inside an industrial plant. As depicted in FIG. 9, a large number of sensors (˜10,000) that are distributed over the plant forward measurement data to process controllers on a periodic or event-driven base. The use case requires support of a large number of sensor devices (10,000) per plant as well as highly reliable transport (packet loss rate<10-5). Further, power consumption is critical since most sensor devices are battery-powered with a targeted battery lifetimes of several years while providing measurement updates every few seconds. A typical process control application supports downstream and upstream flows between process controllers and sensors/actuators which consist of individual transactions. The process controller resides in the plant network. This network interconnects via base stations to the wireless (mesh-) network which hosts the sensor/actuator devices. Typically, each transaction uses less than 100 bytes. For both controller- and sensor/actuator-initiated service flows, upstream and downstream transactions usually occur asynchronously
Second Example—Local UAV Collaboration and Connectivity (5.1.2.4 of 3GPP TR 22.862): Unmanned Aerial Vehicles (UAVs) can collaborate to act as a mobile sensor and actuator network to execute tasks in uncertain and dynamic environments while being controlled by a single user, as illustrated in FIG. 10. Accuracy in sensing tasks is increased when deploying a team of UAVs versus just one as there are multiple vantage points using multiple sensors. Examples of uses for deploying a team of UAVs include: Searching for an intruder or suspect, Continual monitoring of natural disasters, Performing autonomous mapping, and Collaborative manipulation of an object (e.g., picking up corners of a net.), depicts how communication occurs in UAV local vehicle collaboration and connectivity. Both node to node and UAV to mobile network links are required
Example of eMBB Applications:
First Example—Office scenario with High Data Rate Applications (5.1.2 of 3GPP TR 22.862): In an office scenario with high data rate needs, users uses real-time video meeting and frequently upload and download data from company's servers and they are various in size. The productivity is dependent on the efficiency of the system response time and reliability. Dependent on time of day (e.g., morning, evening, weekday vs. weekend etc.) and the location (e.g., shopping mall, downtown street), user expects multi-media traffic upload and download towards internet as well as D2D communications.
Second Example—Office scenario with Higher Density of Connections (5.2.1 of 3GPP TR 22.862): This family covers scenarios with system requirement for the transport of high volume of data traffic per area (traffic density) or transport of data for high number of connections (connection density). One typical scenario enable users to upload and download a very high volume of data from servers, handle high resolution real-time video conferences, etc., while end-users can be under indoor or outdoor and in a densely populated area but with no high mobility needs i.e. up to 60 km/h in urban vehicular. In a hotspot scenario with high user density, depending on time of day (e.g., morning, evening, weekday vs. weekend etc.) and the location (e.g., pedestrians in shopping mall, downtown street, stadium, users in buses in dense city centre), there could be high volume and high capacity multi-media traffic upload and download towards internet. Users can be either indoor or outdoor. Meanwhile when a user is indoors, it is either stationary or nomadic; however, when a user is outdoor it may travel slowly up to 60 km/h. Mobile broadband scenario is to be provided even when terminals enter areas with a high traffic density.
5G Requirements:
3GPP TR 38.913 defines scenarios and requirements for next generation access technologies. The following are excerpts of the Key Performance Indicators (KPI) section of 3GPP TR 38.913 that impose new requirements that are relevant to the light signaling connection topic.
7.17 Connection Density and the need to reduce potential signaling storm: Connection density refers to total number of devices fulfilling specific QoS per unit area (per km2). QoS definition should take into account the amount of data or access request generated within a time t_gen that can be sent or received within a given time, t_sendrx, with x % probability. The target for connection density should be 1 000 000 device/km2 in urban environment. 3GPP should develop standards with means of high connection efficiency (measured as supported number of devices per TRP per unit frequency resource) to achieve the desired connection density.
7.4 Control plane latency: Control plane latency refers to the time to move from a battery efficient state (e.g., IDLE) to start of continuous data transfer (e.g., ACTIVE). The target for control plane latency should be [10 ms].
7.11 UE battery life: UE battery life can be evaluated by the battery life of the UE without recharge. For mMTC, UE battery life in extreme coverage shall be based on the activity of mobile originated data transfer consisting of [200 bytes] UL per day followed by [20 bytes] DL from MCL of [tbd] dB, assuming a stored energy capacity of [5 Wh]. The target for UE battery life should be [10 years].
7.19 Network energy efficiency: The capability is to minimize the RAN energy consumption while providing a much better area traffic capacity. Qualitative KPI as baseline and quantitative KPI is FFS.
7.1 Peak data rate: Peak data rate is the highest theoretical data rate which is the received data bits assuming error-free conditions assignable to a single mobile station, when all assignable radio resources for the corresponding link direction are utilised (i.e., excluding radio resources that are used for physical layer synchronisation, reference signals or pilots, guard bands and guard times). The target for peak data rate should be [20 Gbps] for downlink and [10 Gbps] for uplink.
Network Slicing:
FIG. 11 provides a high level illustration of the concept of network slicing. A network slice is composed of a collection of logical network functions that supports the communication service requirements of particular use case(s). It shall be possible to direct terminals to selected slices in a way that fulfil operator or user needs, e.g., based on subscription or terminal type. The network slicing primarily targets a partition of the core network, but it is not excluded that Radio Access Network (RAN) may need specific functionality to support multiple slices or even partitioning of resources for different network slices. See 3GPP TR 22.891 Feasibility Study on New Services and Markets Technology Enablers (SMARTER); Stage 1 (Release 14) V-1.1.0. (example).
Potential network slicing service requirements defined in 3GPP TR 22.891: 1) The 3GPP System shall allow the operator to compose network slices, i.e. independent sets of network functions (e.g., potentially from different vendors) and parameter configurations, e.g., for hosting multiple enterprises or Mobile virtual network operators (MVNOs) etc.; 2) The operator shall be able to dynamically create network slice to form a complete, autonomous and fully operational network customised to cater for different diverse market scenarios; 3) The 3GPP System shall be able to identify certain terminals and subscribers to be associated with a particular network slice; 4) The 3GPP System shall be able to enable a UE to obtain service from a specific network slice e.g., based on subscription or terminal type.
Potential Network Slicing Operational Requirements defined in 3GPP TR 22.891 include:                The operator shall be able to create and manage network slices that fulfil required criteria for different market scenarios.        The operator shall be able to operate different network slices in parallel with isolation that e.g., prevents data communication in one slice to negatively impact services in other slices.        The 3GPP System shall have the capability to conform to service-specific security assurance requirements in a single network slice, rather than the whole network.        The 3GPP System shall have the capability to provide a level of isolation between network slices which confines a potential cyber-attack to a single network slice.        The operator shall be able to authorize third parties to create, manage a network slice configuration (e.g., scale slices) via suitable Application Program Interfaces (APIs), within the limits set by the network operator.        The 3GPP system shall support elasticity of network slice in term of capacity with no impact on the services of this slice or other slices.        The 3GPP system shall be able to change the slices with minimal impact on the ongoing subscriber's services served by other slices, i.e. new network slice addition, removal of existing network slice, or update of network slice functions or configuration.        The 3GPP System shall be able to support End to End (E2E), e.g., RAN, Core Network (CN), resource management for a network slice.        
Proposals for Small Data Transmission:
RRC Inactive and RRC Connected States have been proposed in S2-161323, as shown in FIG. 12. In S2-161324, a Mobility Framework was proposed as illustrated in FIG. 13.
Requirements Versus the Current State of Art:
The current design for LTE (Rel-12) is not efficient in term of the transition to the RRC-CONNECTED state so a small amount of data can be transmitted or in terms of scalability to support a large number of devices that generate frequent small volumes of data. For frequent small burst transmission, the device wakes up and sends data every few minutes. For the normal procedure, a UE may need to follow the RACH procedure and subsequently establish signaling radio bearers (through RRC connection establishment procedure) and data radio bearers (through RRC Connection reconfiguration procedure). As illustrated in the overall legacy procedure in FIG. 14, the signaling overhead is substantial when considering only a small amount of data is transmitted in the uplink. This is situation is expected to be worst in light of 5G system diverse use cases and traffic profiles.
One key issue identified in the Rel-13 study item as captured in the 3GPP TR 23.720 is the support of infrequent small data transmission for Cellular IoT. This key issue aims to provide solution to support highly efficient handling of infrequent small data transmissions for ultra-low complexity, power constrained, and low data-rate ‘Internet of Things’ devices, called CIoT devices. In 5G systems, it is expected that the number of such devices will increase exponentially but the data size per device and per data transmission event will remain small. Infrequent small data traffic characteristics for MTC applications (as described in Annex E of 3GPP TR 45.820 Cellular system support for ultra-low complexity and low throughput Internet of Things (CIoT) (Release 13), V13.1.0) may lead to inefficient use of resources in the 3GPP system. Another key issue identified in 3GPP TR 23.720 Study on architecture enhancements for Cellular Internet of Things, V13.0.0 is to provide efficient support of tracking devices using small data transmission for Cellular IoT. This key issue aims to provide solution to support highly efficient handling of tracking devices using small data transmissions for ultra-low complexity, power constrained, and low data-rate ‘Internet of Things’ devices, called CIoT devices. It should be noted that excessive signaling will also lead to additional latency and additional power consumption.
Rel-13 LTE has specified two solutions to further reduce signaling overhead for small data transmissions. One solution (Solution 2 in 3GPP TR 23.720), called the control plane (CP) solution, transfers user data between the UE and the core network as a NAS Protocol Data Unit (PDU). The second solution (Solution 18 in 3GPP TR 23.720) allows an RRC Connection to be suspended and at a later time resumed; minimizing the need to go through the full signaling procedure for IDLE to CONNECTED state transition. The solution is applicable both to normal LTE UEs and IOT UEs and is based on enhancements to the IDLE state to make it possible to resume the RRC connection avoiding the need to setup it up again when the UE returns from IDLE, assuming that most of the times the UE returns in a node which has the stored RRC context. The procedure is illustrated in FIG. 15 and FIG. 16.
These release 13 solutions are still suboptimal with many drawbacks:                After RRC connection is suspended,                    The UE transitioned to NAS EMC-IDLE state and therefore no longer has NAS signaling connection. S1 connection is also released. This means signaling overhead both over the air, between the radio access network (RAN) and the core network (CN) as well as within the CN (e.g. between MME and SGW and between SGW and PGW) at the resumption of the RRC connection.            The UE also transitioned to RRC-IDLE state and the execution of a full random access procedure is assumed before the RRC connection is resumed. There is still need to be exchange of RRC Connection Resume/RRC Connection Resume Complete messages with the eNB in order to resume RRC connection.            Only partial access stratum (AS) context is stored which will cause additional signaling overhead to reconfigure the UE after RRC is resumed.            The storage of the AS context in eNB and the storage of non-access stratum context in the core network (MME, SGW and PGW) implies increase storage capacity on both the radio access network and the core network. With an expected density of a million mMTC devices per kilometer square, it is expected that the number of devices in suspended RRC-CONNECTED state per core network node (e.g. MME) and per cell could be quite large in 5G system when compare to the existing LTE system, even if one assume a dense deployment of cells and core network nodes as there is a non-negligible capex and opex deployment cost for the operators. A solution that mainly rely on context storage of large number of devices in the network might not be cost efficient in the context of 5G system            Support for mobility is limited i.e. UE context retrieval is possible only in case X2 interface between source eNB and target eNB is available. If no X2 interface is available, then Signaling Radio Bearers (SRBs) and Data Radio Bearers (DRBs) must be reestablished using the legacy procedure. Furthermore, the contexts stored in the source eNB and even in the core network nodes will have to be cleared through some proprietary implementation means.                        For the first access or anytime the UE has no stored context, it is assumed the legacy RRC Connection establishment procedures (request/response) is used. It should also be noted that the legacy RRC connection establishment procedure is uni-cast transmission based procedure. All of these lead to scalability issue in the context of massive mMTC deployment scenarios anticipated for 5G systems.        The solution does not allow efficient control of UE state transition by the RAN (e.g. eNB), and does not take into account traffic mix and UE mobility due to UE tracking based on NAS tracking area (TA) and UE paging based on NAS DRX configuration. The solution suffers the same limitations as the existing approaches in the prior 3GPP releases where the control of UE state transition between idle mode and connected mode is based on the use of inactivity timer in the eNB. In this approach, the eNB monitor through proprietary methods, traffic activity. When there is no traffic activity according to proprietary configuration and threshold settings for traffic activity detection, the eNB request the core network, specifically the eNB to release the S1 signaling connection. The eNB also releases the RRC signaling connection. NAS signaling connection is also released by the MME and the UE. The effectiveness of this approach depends on the ability of the eNB to clearly configure traffic activity detection, and set the inactivity timer to the right value taking into account various factors such as the traffic type, the UE mobility level, the targeted user experience level, etc. Furthermore, in an ideal solution, the inactivity timer value should be adjusted dynamically. It has been observed in LTE networks that inactivity timers are typically configured to be quite short (down to 10-20 seconds) which leads to a high amount of transitions from RRC_IDLE to RRC_CONNECTED. This state transition is quite costly in terms of signaling considering that the majority of the RRC connections in LTE transfer less than 1 Kbyte of data to then move back to RRC_IDLE. Similarly, non-optimal configuration of Rel-13 NB-IOT solutions will limit the applicability of these solutions, and even the limited anticipated signaling overhead reduction with the use of this solution might not be realized.        
The next generation of wireless communication systems are expected to support a wide range of use cases with varying requirements ranging from fully mobile devices to stationary IOT or fixed wireless broadband devices. The traffic pattern associated with many use cases is expected to consist of short or long bursts of data traffic with varying length of waiting period in between.
The drawbacks of Rel-13 NB-IOT solutions listed above highlight the need for further enhancements to the handling of small and infrequent data transmission, and not just for stationary NB-IoT/mMTC devices but also for all UEs that are mobile. More specifically: 1) The current signaling overhead for small and infrequent data transmissions is still too prohibitive and needs to be reduced further in order to meet 5G requirements of signaling storm reduction and spectrum efficiency by 3 times over IMT-Advanced; 2) Increased storage of AS and NAS context in the network implies increased network Capex and Opex which negatively impacts the requirement to minimize 5G network deployment and operational costs; 3) Excessive signaling also leads to additional latency. The current RRC connection setup latency (i.e. 120 ms for mobile originated calls and 280 ms for mobile terminated calls, see RP-160301) still need to be further reduced to improve the end user experience and meet 5G requirement on control plane latency which could be 10 ms or less for some of the use cases (e.g. Ultra Reliable and Low latency applications); and 4) Excessive signaling also leads to additional UE power consumption and additional network energy consumption and will negatively impact the ability of the system to meet the UE Battery Life requirements of 10 years defined in section 7.11 of 3GPP TR 38.913 and the Network Energy Efficiency requirements defined in section 7.19 of 3GPP TR 38.913.
New proposals for enhancement to small data transmission handling, aimed specifically at further reducing signaling overhead and addressed the above identified drawbacks of the Rel-13 NB-IOT solutions are emerging. Various high level solution ideas are already being proposed in the context of 5G discussion for e.g., in 3GPP System Aspects Working Group 2 (SA WG2 or simply SA2), High level ideas that are being proposed for further explorations include: 1) Further reduce NAS signaling and signaling to CN over S1 interface due to mobility and idle/active transition by further developing the following ideas: a) Re-use the Rel-13 suspend/resume solution with UE context stored while the UE is in RRC_IDLE or create a new UE-controlled mobility based RRC-CONNECTED state but hide such suspend/resume state or any such new intermediary state from the core network; b) RAN originated paging message; and c) Use Anchor/Gateway function in RAN to allow context fetch upon cell reselection and data reforwarding. Other ideas include: 2) Further enhancements to allow RAN to choose optimum parameters such as flexibility for RAN to control UE specific tracking area that could be different than core network based tracking area; and 3) Further enhancements to allow RAN to choose optimum parameters such as flexibility for RAN to adjust DRX parameters applicable in lightly connected state (e.g. UE controlled mobility connected state) for example allows RAN to optimize DRX taking into account UE's current data QoS Requirements.